1. Field of the Invention
The present invention relates generally to computer software and computer network applications. More specifically, it relates to client configuration databases and managing transactions in a configuration database.
2. Discussion of Related Art
One type of conventional computer network involves connecting a series of personal computers referred to as clients (e.g., Sun SPARC workstations or IBM PCs), to one or more server computers. The client computers are generally self-sufficient and contain within their own memory much of the information needed to run user applications and perform network operations. That is, they contain information regarding their own configuration with regard to both software and hardware capabilities and requirements. The client computers typically access the network servers for a variety of reasons such as, for example, accessing network software applications, sending and receiving email, retrieving and storing information on a network database. However, information specific to a particular client computer generally resides on the client computer. This information can include, for example, the amount of memory or databus types, hardware specifications, such as what type of databus or additional processors. Since the client computers are relatively self-sufficient and store their own configuration information (and, thus is not available on the server computer), the task of data and application management on a client computer has become increasingly burdensome.
Although it is possible to propagate minor changes or fixes to applications that reside on a server on the network to the client computers, any significant upgrade or fix, or installation of a new application that effects every client requires that each client computer be accessed and updated individually by a network administrator. With the increasing number of computers being connected to networks ranging in the tens of thousands in some enterprises, the burden of installing major revisions or upgrades to application software or to general configuration software has become expensive, inefficient, and time-consuming.
Present configuration databases in distributed computing environments, particularly those that utilize network computers, lack adequate transaction management tools and features. For example, configuration database systems and protocols do not support fully functional locking capability to handle read-only transactions or exclusive transactions. Another feature lacking in such database systems and protocols as described above is what is referred to as atomicity, or the ability to guarantee that a transaction in the database was either fully completed or not completed. These features are important practical considerations in the day-to-day use of a configuration database. In addition, transactions in prior art configuration databases lack invisibility to the application; in other words, the application must explicitly identify the transaction and how the transaction should be performed. This is in contrast to simply specifying what needs to be done and allowing the configuration database to handle the transaction in the most efficient manner without intervention from the application.
Therefore, in the context of managing transactions in the configuration database, it would be desirable to have transaction management in a configuration database that allows for atomicity and locking. It would also be desirable to have a transaction management framework which behaves as a core base feature in that applications do not have to instruct or oversee the completion of the transaction, if it chooses not to do so. The application should simply indicate that it wants to complete a particular operation and that the configuration database should do whatever it believes is necessary to guarantee the atomicity of the operation.